Hi there, I'm having trouble getting message routing to exchange 2003 servers running in one of my sites. I have Exchange 2007 installed in two sites and created one routing group connector for traffic to and from Exchange 2003. This connector contains 1 hub transport server of one Exchange 2007 site. All routing connections within the Exchange 2003 environment are setup correctly.I did not supress link state as this is the only RG connector for Exchange 2007.Winroute shows all connections in Exchange 2003 to be up and running. Messages sent from Exchange 2003 are delivered correctly to both my Exchange 2007 sites. Mail from the Exchange 2007 site where the routing group connector is homed to Exchange 2003 is also working correctly. Mail within the Exchange 2007 ' routing group' is also working correctly. Only thing not working is mailflow from the other Exchange 2007 site to Exchange 2003. The transport hubs in the other site are queuing messages in their unreachable queues and generating the following eventID's 5016 : The Active Directory topology service could not discover any route to connector ........ 5015 : Microsoft Exchange cannot find a route to the source transport server or home MTA server ......... 5009 : Microsoft Exchange cannot find the route to mailbox database .......... 5006 : Cannot find route to Mailbox Server ........ 5020 : The topology doesnt contain a route to Exchange 2000 Server or Exchange Server 2003 server....... The events are generated for all E2K3 connectors, corresponding bridgeheads, E2K3 pf/mbx databases. It seems like the Active Directory topology service is malfunctioning somehow. I tried to recreate the routing group connector using powershell and even recreated the sitelinks, but nothing seems to help. Even the mailflow troubleshooter only refers to the event id's. Any ideas? Regards, Mark

It sounds as if your configuration is all correct, but for some reason the 2007 Hub server in the second site has not updated its routing table to detect the route through the first site to the routing group connector and then to 2003. The error messages all indicate that recipient resolution happened okay, the server just can't figure out how to get to its destination. What's the Active Directory replication schedule between the two sites? It's possible that the site does not yet know about the routing group connector. If you can, try forcing Active Directory replication between the two sites. An AD notification of configuration changes should cause the routing tables to update. I hope this helps. If not, repost and I'll investigate more.

Hi Kate, Well I found something really strange this morning after comparing the routing configuration logs in both sites and the output of the get-routinggroupconnector cmdlet.This is what is causing it... The connector used to connect to Exchange is missing from the routing configuration. Also the routing config does not match .. Look at the guids .... how is this possible???? The topology should be refreshed after a routing change right?? Also not all hub transports need to be included in the routinggroupconnector source transportservers right??? Routinglog SITE1 (the one connected to 2003) - <RoutingGroupConnector ID="RoutingGroupConnector3"> <Id>58279677-023c-4441-a944-99c65b067eac</Id> <DN>CN=UTC Connection,CN=Connections,CN=Exchange Routing Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=TestInt,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=test,DC=com</DN> <Name>UTC Connection</Name> <TargetGroupDN>CN=Europe,CN=Routing Groups,CN=Backbone,CN=Administrative Groups,CN=TestInt,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=test,DC=com</TargetGroupDN> <Cost>10</Cost> </RoutingGroupConnector>- <RoutingGroupConnector ID="RoutingGroupConnector4"> <Id>9401b62a-d799-42fc-895d-7af54638c43a</Id> <DN>CN=UTC Connection,CN=Connections,CN=Europe,CN=Routing Groups,CN=Backbone,CN=Administrative Groups,CN=TestInt,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=test,DC=com</DN> <Name>UTC Connection</Name> <TargetGroupDN>CN=Exchange Routing Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=TestInt,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=test,DC=com</TargetGroupDN> <Cost>10</Cost> </RoutingGroupConnector> Routinglog SITE2(the one not connected to 2003 directly) - <RoutingGroupConnector ID="RoutingGroupConnector3"> <Id>6829aa94-3fd2-4f79-9d93-636a8a17ddbe</Id> <DN>CN=UTC Connection,CN=Connections,CN=Europe,CN=Routing Groups,CN=Backbone,CN=Administrative Groups,CN=TestInt,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=test,DC=com</DN> <Name>UTC Connection</Name> <TargetGroupDN>CN=Exchange Routing Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=TestInt,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=test,DC=com</TargetGroupDN> <Cost>10</Cost> </RoutingGroupConnector> Output CMDLET: Name Guid---- ----UTC Connection d8e7c461-7788-4a64-9134-ca715e72e1abUTC Connection 6829aa94-3fd2-4f79-9d93-636a8a17ddbe

Well, I recreated the routing group connector using: New-RoutingGroupConnector -Name "UTC Connection" -SourceTransportServers "UTCS121T71.eu.test.com" -TargetTransportServers "LONS121T01.eu.test.com","ZSTS121T01.eu.test.com" -Cost 10 -BiDirectional $true -PublicFolderReferralsEnabled $true In the directly connected site, all is fine. The guids now match. However in the remote site the problem still occurs. The outgoing connector is not showing up in the routing config. Cheers, Mark

I opened a supportcase at MS support. Will update this post periodically.

Well.... Microsoft was not able to fix it and stopped the support, because the Exchange environment was hosted on VMWARE. I've rebuild part of the environment on Virtual Server, in which I encountered other problems. After some troubleshooting I noticed some discrepencies between the rightsassignements on certain exchange containers in the config partion on the new york and utrecht domain controllers. after making some changes in the ACL's on the utrecht domain controller and replicating it to new york, the issues where over. After some more digging we found that due to skewed system times on some US DC's replication was not working properly. The strange thing was that there was no logging on the DC's I used that indicated a direct issue..... Ohwell. At least it's solved now.